EKS Auto Mode でノードのログを回収してみる
2025.01.08EKS Auto Mode ではノードとなる EC2 が AWS 管理となることから、直接ホストに SSH や Session Manager でログインすることができません。
一方で、ノード内のログを S3 に出力することは可能です。
この仕組みは最近発表された、ノード監視エージェント前提を活用した仕組みのようです。
An existing Amazon EKS cluster with the node monitoring agent. For more information, see Enable node auto repair and investigate node health issues.
https://docs.aws.amazon.com/eks/latest/userguide/auto-get-logs.html
EKS Auto Mode の場合は必ずノード監視エージェントがインストールされているので、インストールされているかどうかを気にする必要はありません。
基本はノード監視エージェントが情報を集めてくれるのでマネジメントコンソールから状態を確認しつつ、どうしてもログが見たい場合に活用するイメージになりそうです。
では、公式ドキュメントに沿ってログを取得してみます。
まず、出力先の S3 バケットを作成します。
S3 への出力は署名付き URL を利用するので、バケットポリシー等で許可を与える必要はありません。
% aws s3api create-bucket --bucket masukawa-eks-auto-log-bucket --create-bucket-configuration LocationConstraint=ap-northeast-1 --region ap-northeast-1
ドキュメントで紹介されているスクリプトを利用して、署名付き URL を作成します。
作成したバケット名と出力時のキーを設定して実行します。
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': 'BucketName', 'Key': 'Key'},
ExpiresIn=1000
))
署名付き URL と取得対象のインスタンス ID を指定して、NodeDiagnostic リソースを作成します。
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name: i-008333ed6498b80ce
spec:
logCapture:
destination: <署名付きURL>
Status が Success ではなく SuccessWithErrors になってしまうのですが、ログは取れてそうなので進めます(SuccessWithErrors になってしまう理由は掴めませんでした...)。
% kubectl describe nodediagnostics.eks.amazonaws.com/i-008333ed6498b80ce
Name: i-008333ed6498b80ce
Namespace:
Labels: <none>
Annotations: <none>
API Version: eks.amazonaws.com/v1alpha1
Kind: NodeDiagnostic
Metadata:
Creation Timestamp: 2025-01-08T09:13:47Z
Generation: 1
Resource Version: 87813
UID: b723c906-2c48-4da4-8395-92baa092932f
Spec:
Log Capture:
Categories:
All
Destination: https://xxxxxxxxxx
Status:
Capture Statuses:
State:
Completed:
Finished At: 2025-01-08T09:13:49Z
Message: successfully uploaded logs with some errors
Reason: SuccessWithErrors
Started At: 2025-01-08T09:13:47Z
Type: Log
Events: <none>
どうやら一部ログが取得できないと、SuccessWithErrors になるようです。
A status of Success or SuccessWithErrors indicates that the task completed and the logs uploaded to the provided destination (SuccessWithErrors indicates that some logs might be missing)
https://docs.aws.amazon.com/eks/latest/userguide/auto-get-logs.html
S3 にログが出力されているので、ダウンロードして解凍します。
mkdir tmp && cd tmp
aws s3 cp s3://bucket-name/key ./node-logs.tar.gz
tar -zxvf node-logs.tar.gz
ディレクトリ構成は下記のようになりました。
% tree .
.
├── bottlerocket
│ └── application-inventory.json
├── cni
│ └── 10-aws.conflist
├── containerd
│ ├── containerd-config.txt
│ ├── containerd-containers.txt
│ ├── containerd-images.txt
│ ├── containerd-log.txt
│ ├── containerd-namespaces.txt
│ ├── containerd-plugins.txt
│ ├── containerd-tasks.txt
│ └── containerd-version.txt
├── ipamd
│ ├── ipam.json
│ └── metrics.json
├── kernel
│ ├── dmesg.current
│ ├── dmesg.human.current
│ └── uname.txt
├── kubelet
│ ├── config.json
│ ├── kubeconfig.yaml
│ ├── kubelet.log
│ └── kubelet_service.txt
├── log-capture-errors.log
├── networking
│ ├── configure-multicard-interfaces.txt
│ ├── conntrack.txt
│ ├── conntrack6.txt
│ ├── ethtool.txt
│ ├── get_api_server.txt
│ ├── ip6route.txt
│ ├── ip6rule.txt
│ ├── ip6tables-filter.txt
│ ├── ip6tables-mangle.txt
│ ├── ip6tables-nat.txt
│ ├── ip6tables-save.txt
│ ├── ip6tables.txt
│ ├── iproute.txt
│ ├── iprule.txt
│ ├── iptables-filter.txt
│ ├── iptables-mangle.txt
│ ├── iptables-nat.txt
│ ├── iptables-save.txt
│ ├── iptables.txt
│ └── resolv.conf
├── nodeadm
│ ├── nodeadm-config.log
│ └── nodeadm-run.log
├── sandbox-image
│ └── sandbox-image-log.txt
├── storage
│ ├── inodes.txt
│ ├── lsblk.txt
│ ├── mounts.txt
│ ├── pod_local_storage.txt
│ └── xfs.txt
├── sysctls
│ └── sysctl_all.txt
├── system
│ ├── allprocstat.txt
│ ├── availability-zone.txt
│ ├── cpu_throttling.txt
│ ├── instance-id.txt
│ ├── io_throttling.txt
│ ├── procstat.txt
│ ├── ps-threads.txt
│ ├── ps.txt
│ ├── region.txt
│ ├── services.txt
│ └── top.txt
└── var_log
└── aws-routed-eni
├── ebpf-sdk.log
├── ipamd.log
├── network-policy-agent.log
└── plugin.log
15 directories, 64 files
ちなみに、Auto Mode の裏で動作している Karpenter や AWS LoadBalancer Controller はそもそも Node にインストールされないので、ログを取得することはできないです。
今後のアップデートで見れるようになることに期待したいですね。
また、application-inventory.json から EBS CSI driver や Pod Identity Agent がインストールされていることは確認できましたが、ログを確認できませんでした(やり方の問題かもしれませんが...)。
あくまでノード監視エージェントで検知された時にさらなる調査のために利用する機能のようです。
KubeletFailed が検知された時に kubelet/kubelet.log を確認したり、ネットワーク関連のエラーが出た際に iproute の設定やルート情報を確認したりといったユースケースで活用できそうです。
system/ps.txt からプロセスの状態なんかもバッチリ取れています！
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2 0.0 0.0 0 0 ? S 06:10 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [rcu_gp]
root 4 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [rcu_par_gp]
root 5 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [slub_flushwq]
root 6 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [netns]
root 8 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kworker/0:0H-kblockd]
root 10 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [mm_percpu_wq]
root 11 0.0 0.0 0 0 ? I 06:10 0:00 \_ [rcu_tasks_kthread]
root 12 0.0 0.0 0 0 ? I 06:10 0:00 \_ [rcu_tasks_rude_kthread]
root 13 0.0 0.0 0 0 ? I 06:10 0:00 \_ [rcu_tasks_trace_kthread]
root 14 0.0 0.0 0 0 ? S 06:10 0:00 \_ [ksoftirqd/0]
root 15 0.0 0.0 0 0 ? I 06:10 0:00 \_ [rcu_preempt]
root 16 0.0 0.0 0 0 ? S 06:10 0:00 \_ [migration/0]
root 18 0.0 0.0 0 0 ? S 06:10 0:00 \_ [cpuhp/0]
root 19 0.0 0.0 0 0 ? S 06:10 0:00 \_ [cpuhp/1]
root 20 0.0 0.0 0 0 ? S 06:10 0:00 \_ [migration/1]
root 21 0.0 0.0 0 0 ? S 06:10 0:00 \_ [ksoftirqd/1]
root 23 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kworker/1:0H-events_highpri]
root 26 0.0 0.0 0 0 ? S 06:10 0:00 \_ [kdevtmpfs]
root 27 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [inet_frag_wq]
root 28 0.0 0.0 0 0 ? S 06:10 0:00 \_ [kauditd]
root 29 0.0 0.0 0 0 ? S 06:10 0:00 \_ [khungtaskd]
root 30 0.0 0.0 0 0 ? S 06:10 0:00 \_ [oom_reaper]
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 32 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [writeback]
root 33 0.0 0.0 0 0 ? S 06:10 0:00 \_ [kcompactd0]
root 34 0.0 0.0 0 0 ? SN 06:10 0:00 \_ [khugepaged]
root 35 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [cryptd]
root 36 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kintegrityd]
root 37 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kblockd]
root 38 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [blkcg_punt_bio]
root 40 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [tpm_dev_wq]
root 41 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [ata_sff]
root 42 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [md]
root 43 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [edac-poller]
root 44 0.0 0.0 0 0 ? S 06:10 0:00 \_ [watchdogd]
root 45 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kworker/1:1H-kblockd]
root 68 0.0 0.0 0 0 ? S 06:10 0:00 \_ [kswapd0]
root 71 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfsalloc]
root 72 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs_mru_cache]
root 76 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kthrotld]
root 138 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [nvme-wq]
root 141 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [nvme-reset-wq]
root 143 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [nvme-delete-wq]
root 149 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [dm_bufio_cache]
root 188 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [mld]
root 189 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [ipv6_addrconf]
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 199 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kstrp]
root 219 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [zswap-shrink]
root 340 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kdmflush/252:0]
root 341 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kverityd]
root 346 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [ext4-rsv-conver]
root 348 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [kworker/0:1H-xfs-log/nvme1n1p1]
root 409 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [ext4-rsv-conver]
root 893 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [ena]
root 922 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-buf/nvme1n1]
root 923 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-conv/nvme1n]
root 924 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-reclaim/nvm]
root 925 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-blockgc/nvm]
root 926 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-inodegc/nvm]
root 927 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-log/nvme1n1]
root 928 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [xfs-cil/nvme1n1]
root 929 0.0 0.0 0 0 ? S 06:10 0:01 \_ [xfsaild/nvme1n1p1]
root 951 0.0 0.0 0 0 ? S 06:10 0:00 \_ [jbd2/nvme0n1p7-8]
root 952 0.0 0.0 0 0 ? I< 06:10 0:00 \_ [ext4-rsv-conver]
root 2293 0.0 0.0 0 0 ? I 06:18 0:00 \_ [kworker/1:1-events_power_efficient]
root 2716 0.0 0.0 0 0 ? I< 06:27 0:00 \_ [kworker/u5:2-kverityd]
root 2923 0.0 0.0 0 0 ? I 06:27 0:00 \_ [kworker/0:1-events]
root 3735 0.0 0.0 0 0 ? I 06:42 0:00 \_ [kworker/0:2-xfs-inodegc/nvme1n1p1]
root 6163 0.0 0.0 0 0 ? I< 07:37 0:00 \_ [kworker/u5:0]
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 9276 0.0 0.0 0 0 ? I 08:51 0:00 \_ [kworker/u4:2-writeback]
root 9820 0.0 0.0 0 0 ? I 09:05 0:00 \_ [kworker/u4:1-events_unbound]
root 9838 0.0 0.0 0 0 ? I 09:05 0:00 \_ [kworker/1:0-events]
root 10044 0.0 0.0 0 0 ? I 09:10 0:00 \_ [kworker/1:2-events_power_efficient]
root 1 0.2 0.3 98268 12948 ? Ss 06:10 0:25 /sbin/init systemd.log_target=journal-or-kmsg systemd.log_color=0 systemd.show_status=true
root 383 0.0 0.5 34448 19972 ? Ss 06:10 0:01 /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/systemd-journald
root 415 0.0 0.1 11292 7036 ? Ss 06:10 0:00 /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/systemd-udevd
dbus 1003 0.0 0.0 7672 3900 ? Ss 06:10 0:00 /usr/bin/dbus-broker-launch --scope system
dbus 1004 0.0 0.0 4496 2960 ? S 06:10 0:03 \_ dbus-broker --log 4 --controller 9 --machine-id ec291fc777103f58b82d804f142d0426 --max-bytes 536870912 --max-fds 4096 --max-matches 16384
root 1009 0.0 0.1 10120 6200 ? Ss 06:10 0:00 /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/systemd-logind
systemd+ 1012 0.0 0.1 7184 4780 ? Ss 06:10 0:00 /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/systemd-networkd
root 1023 0.0 0.2 145984 8916 ? Ssl 06:10 0:01 /usr/bin/apiserver --datastore-path /var/lib/bottlerocket/datastore/current --socket-gid 274
systemd+ 1113 0.0 0.1 10224 6540 ? Ss 06:11 0:00 /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/systemd-resolved
chrony 1132 0.0 0.0 12092 2748 ? Ss 06:11 0:00 /usr/sbin/chronyd -d -F -1
chrony 1134 0.0 0.0 3764 152 ? S 06:11 0:00 \_ /usr/sbin/chronyd -d -F -1
root 1142 0.0 1.2 1805712 47072 ? Ssl 06:11 0:04 /usr/bin/aws-network-policy-agent --kubeconfig /etc/kubernetes/aws-network-policy-agent/kubeconfig --enable-network-policy true --health-probe-bind-addr 127.0.0.1:8901 --metrics-bind-addr 127.0.0.1:8900
root 1143 0.2 1.6 1950500 63872 ? Ssl 06:11 0:28 /usr/bin/containerd
root 1165 0.0 1.1 2126152 46400 ? Ssl 06:11 0:07 /usr/bin/eks-healthchecker
root 1167 0.0 1.5 1741452 60212 ? Ssl 06:11 0:02 /usr/bin/kube-proxy --hostname-override i-008333ed6498b80ce --config=/usr/share/kube-proxy/kube-proxy-config --kubeconfig=/etc/kubernetes/kube-proxy/kubeconfig
root 1220 0.0 0.4 1906732 16904 ? Ssl 06:11 0:01 /usr/bin/eks-pod-identity-agent server --metrics-address 127.0.0.1 --cluster-name test-cluster --port 80 --probe-port 2703 --verbosity trace
root 1234 0.5 2.3 2124280 93576 ? Ssl 06:11 1:02 /usr/bin/kubelet --cloud-provider external --kubeconfig /etc/kubernetes/kubelet/kubeconfig --config /etc/kubernetes/kubelet/config --container-runtime-endpoint=unix:///run/containerd/containerd.sock --containerd=/run/containerd/containerd.sock --root-dir /var/lib/kubelet --cert-dir /var/lib/kubelet/pki --image-credential-provider-bin-dir /usr/libexec/kubernetes/kubelet/plugins --image-credential-provider-config /etc/kubernetes/kubelet/credential-provider-config.yaml --hostname-override i-008333ed6498b80ce --node-ip 10.0.100.82 --node-labels eks.amazonaws.com/nodeclass=default,karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=general-purpose --register-with-taints karpenter.sh/unregistered=:NoExecute --pod-infra-container-image localhost/kubernetes/pause:0.1.0 --runtime-cgroups=/runtime.slice/containerd.service
root 1257 0.0 0.5 1764688 21728 ? Ssl 06:11 0:00 /usr/bin/csi-node-driver-registrar --csi-address=/var/lib/kubelet/plugins/ebs.csi.eks.amazonaws.com/csi.sock --kubelet-registration-path=/var/lib/kubelet/plugins/ebs.csi.eks.amazonaws.com/csi.sock --plugin-registration-path=/var/lib/kubelet/plugins_registry
root 1272 0.0 1.3 1680960 54600 ? Ssl 06:11 0:00 /usr/bin/eks-ebs-csi-driver node --kubeconfig /etc/kubernetes/eks-ebs-csi-driver/kubeconfig --endpoint=unix:/var/lib/kubelet/plugins/ebs.csi.eks.amazonaws.com/csi.sock
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1606 0.2 1.3 2326524 54076 ? Ssl 06:11 0:26 /usr/bin/eks-node-monitoring-agent --kubeconfig /etc/kubernetes/eks-node-monitoring-agent/kubeconfig --hostname-override i-008333ed6498b80ce --console-diagnostics --probe-address localhost:8800 --metrics-address localhost:8801
root 10266 0.0 0.0 4488 3204 ? R 09:13 0:00 \_ ps fauxwww --headers
root 1673 0.0 1.7 1650268 67124 ? Ssl 06:11 0:04 /usr/bin/ipamd --kubeconfig /etc/kubernetes/ipamd/kubeconfig --metrics-bind-addr 127.0.0.1:8172 --health-probe-bind-addr 127.0.0.1:8173
coredns 1696 0.1 1.7 1822436 66452 ? Ssl 06:11 0:16 /usr/bin/coredns -conf=/etc/coredns/Corefile
root 1811 0.0 0.5 2060384 20040 ? Sl 06:11 0:01 /x86_64-bottlerocket-linux-gnu/sys-root/usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id db489fc06fd8c3ad0c41980237d3f07ed8a13926e7d13e12ea2c1f2dec82fb8a -address /run/containerd/containerd.sock
root 1839 0.0 0.0 196 4 ? Ss 06:11 0:00 \_ /pause
root 1899 0.0 0.1 32636 5240 ? Ss 06:11 0:00 \_ nginx: master process nginx -g daemon off;
101 1921 0.0 0.0 33084 3140 ? S 06:11 0:00 \_ nginx: worker process
マネージドな状態で実行されているコンポーネントのログを全て取得できるわけではないですが、トラブルシューティングの時は便利に使えそうです。
簡単な手順で取得できるので、是非試してみて下さい！
